[{"data":1,"prerenderedAt":911},["ShallowReactive",2],{"tag-data-event driven architecture":3},[4],{"id":5,"title":6,"alt":7,"authors":8,"body":15,"date":888,"description":889,"extension":890,"image":891,"meta":892,"navigation":893,"ogImage":891,"path":894,"published":893,"reviewers":895,"seo":902,"stem":903,"tags":904,"__hash__":910},"blogs\u002Fblogs\u002F2026-05-04-mainframe-aws-reconcilier-deux-mondes-grace-a-levent-driven\u002Findex.md","Mainframe & AWS : Réconcilier deux mondes grâce à l'Event-Driven","Comparaison visuelle entre un mainframe vintage des années 70 et un centre de données cloud moderne, reliés par un flux de données numérique bidirectionnel symbolisant la transformation numérique.",[9],{"id":10,"name":11,"image":12,"linkedin":13,"x":14},"838dec96-f9fc-404f-a302-07719225d785","Maxime Deroullers",".\u002Fassets\u002Fauthor-maxime-deroullers.webp","https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fmaxime-deroullers-1b5791137\u002F","https:\u002F\u002Fx.com\u002Fmderoullers",{"type":16,"value":17,"toc":859},"minimark",[18,22,27,30,38,45,60,63,67,73,76,83,88,120,124,148,152,173,180,186,290,300,304,308,314,317,336,340,343,386,390,393,422,429,433,439,442,466,469,473,480,484,529,533,556,560,563,577,580,584,590,593,618,629,633,636,646,649,669,672,676,679,683,731,735,755,759,766,770,802,806,813,817,820,823,826,852,855],[19,20,21],"p",{},"Comment réconcilier 80 à 90 % des données métier coincées dans un Mainframe IBM avec des applications cloud-native qui exigent l'instantané ? Retour d'expérience sur la construction d'un pont event-driven entre le Mainframe et AWS sans toucher à une seule ligne de COBOL.",[23,24,26],"h2",{"id":25},"_1-lexpérience-utilisateur-dabord-le-conseiller-aveugle","1. L’expérience utilisateur d’abord : le conseiller \"aveugle\"",[19,28,29],{},"Imaginez un conseiller en banque privée, censé offrir un service d'excellence à des clients exigeants. Pourtant, chaque matin, il commence sa journée avec un handicap majeur : il est \"aveugle\" sur les dernières 24 heures.",[19,31,32,33,37],{},"Si son client a effectué un virement important, soldé une assurance-vie ou reçu des fonds hier après-midi, le conseiller ne le voit pas.\nPourquoi ?\nParce que le système d'information repose sur des ",[34,35,36],"strong",{},"batchs de nuit",". Les données sont traitées en masse, une fois par jour. Pire, si le batch \"plante\" la nuit (ce qui arrive), le retard s'accumule, et l'aveuglement dure 48 heures.",[19,39,40,41,44],{},"Prenons un exemple concret. Un client demande un arbitrage sur son assurance-vie via le portail web. L'opération est traitée par le système de gestion des contrats, mais l'intégration automatique échoue (dans notre contexte, 5 à 20% des cas selon les opérations). Résultat : le dossier reste \"en sommeil\" dans l'application documentaire, invisible pour le gestionnaire. Le client attend, relance, s'impatiente. Le problème n'est pas un bug, c'est un ",[34,42,43],{},"défaut d'architecture",".",[19,46,47,48,51,52,55,56,59],{},"C'est le choc des cultures. D'un côté, un ",[34,49,50],{},"Mainframe IBM"," (le \"Vieux Monde\"), robuste, sécurisé, mais rigide et rythmé par ses batchs quotidiens. Dans notre contexte, il concentre ",[34,53,54],{},"80 à 90% des données métier"," de l'entreprise, un poids incontournable. De l'autre, des applications modernes sur ",[34,57,58],{},"AWS"," (le \"Nouveau Monde\"), conçues pour l'instantanéité et l'expérience utilisateur fluide.",[19,61,62],{},"Notre mission ? Réconcilier ces deux mondes.",[23,64,66],{"id":65},"_2-le-défi-technique-faire-parler-un-dinosaure","2. Le défi technique : faire parler un dinosaure",[19,68,69,70,44],{},"Le problème fondamental est architectural : ",[34,71,72],{},"le COBOL n'est pas conçu pour l'événementiel",[19,74,75],{},"Les programmes Legacy sont procéduraux. Ils traitent des fichiers, pas des flux. Leur demander d'émettre un événement HTTP ou d'appeler une API à chaque transaction est risqué (latence, couplage fort) et complexe (réécriture de code critique vieux de 30 ans).",[19,77,78,79,82],{},"Nous avons évalué plusieurs architectures candidates, regroupées en ",[34,80,81],{},"trois grandes familles",", récapitulées dans le schéma plus bas :",[84,85,87],"h3",{"id":86},"solution-a-rabbitmq-via-lambda-bridge","Solution A : RabbitMQ via Lambda Bridge",[19,89,90,97,98,103,104,109,115,116,119],{},[91,92,96],"a",{"href":93,"rel":94},"https:\u002F\u002Fwww.rabbitmq.com\u002F",[95],"nofollow","RabbitMQ"," (via ",[91,99,102],{"href":100,"rel":101},"https:\u002F\u002Faws.amazon.com\u002Famazon-mq\u002F",[95],"Amazon MQ",") offre un routage intelligent natif et, depuis la v3.9, un ",[91,105,108],{"href":106,"rel":107},"https:\u002F\u002Fwww.rabbitmq.com\u002Fstreams.html",[95],"mode ",[91,110,112],{"href":106,"rel":111},[95],[34,113,114],{},"Stream"," combinant messaging classique et event-streaming. L'option la plus économique serait une connexion AMQP directe depuis le COBOL, mais elle exigeait de réécrire les programmes Mainframe. Les variantes plus sûres reposent sur un ",[34,117,118],{},"bridge Lambda"," entre IBM MQ et Amazon MQ, au prix de code custom à écrire et maintenir.",[84,121,123],{"id":122},"solution-b-kafka-connect-la-gagnante","Solution B : Kafka Connect, la gagnante",[19,125,126,131,132,137,138,143,144,147],{},[91,127,130],{"href":128,"rel":129},"https:\u002F\u002Fkafka.apache.org\u002Fdocumentation\u002F#connect",[95],"Kafka Connect"," (associé à ",[91,133,136],{"href":134,"rel":135},"https:\u002F\u002Faws.amazon.com\u002Fmsk\u002F",[95],"Amazon MSK",") consomme directement IBM MQ via un ",[91,139,142],{"href":140,"rel":141},"https:\u002F\u002Fgithub.com\u002Fibm-messaging\u002Fkafka-connect-mq-source",[95],"connecteur officiel IBM Event Streams",". Le Mainframe continue de déposer ses messages dans ses files MQ comme il l'a toujours fait ; le connecteur les réplique en topics Kafka et inversement. Aucune ligne de code custom : tout se pilote par configuration. C'est l'approche ",[34,145,146],{},"\"Configuration over Code\""," qui a tranché.",[84,149,151],{"id":150},"solution-c-zos-connect-rest-hybride","Solution C : z\u002FOS Connect (REST hybride)",[19,153,154,155,162,163,168,169,172],{},"Utiliser ",[91,156,159],{"href":157,"rel":158},"https:\u002F\u002Fwww.ibm.com\u002Fproducts\u002Fzos-connect",[95],[34,160,161],{},"z\u002FOS Connect"," pour exposer des API REST depuis le Mainframe vers le broker AWS. Avantage : supprime la dépendance à ",[91,164,167],{"href":165,"rel":166},"https:\u002F\u002Fwww.ibm.com\u002Fproducts\u002Fmq",[95],"IBM MQ",". Inconvénient majeur : on perd la ",[34,170,171],{},"transactionnalité native",", il faut recréer la gestion de transactions côté applicatif.",[19,174,175],{},[176,177],"img",{"alt":178,"src":179},"Comparatif des trois solutions techniques évaluées : RabbitMQ via Lambda Bridge, Kafka Connect (retenu) et z\u002FOS Connect en REST hybride.","\u002Fcontent-assets\u002F2026-05-04-mainframe-aws-reconcilier-deux-mondes-grace-a-levent-driven\u002Fassets\u002Fimg1.webp",[19,181,182,183,44],{},"Elle a gagné sur un critère décisif : ",[34,184,185],{},"zéro modification du code COBOL",[187,188,189,207],"table",{},[190,191,192],"thead",{},[193,194,195,199,201,204],"tr",{},[196,197,198],"th",{},"Critère",[196,200,96],{},[196,202,203],{},"Kafka (MSK)",[196,205,206],{},"ActiveMQ",[208,209,210,225,239,252,266,279],"tbody",{},[193,211,212,216,219,222],{},[213,214,215],"td",{},"Débit",[213,217,218],{},"20-50K msg\u002Fs",[213,220,221],{},"50-100K msg\u002Fs par partition (millions sur un cluster)",[213,223,224],{},"10-20K msg\u002Fs",[193,226,227,230,233,236],{},[213,228,229],{},"Replay natif",[213,231,232],{},"Via extension Stream",[213,234,235],{},"Excellent (log persistant)",[213,237,238],{},"Limité",[193,240,241,244,247,250],{},[213,242,243],{},"Scalabilité",[213,245,246],{},"Bonne",[213,248,249],{},"Excellente",[213,251,246],{},[193,253,254,257,260,263],{},[213,255,256],{},"Routage intelligent",[213,258,259],{},"Oui (exchanges)",[213,261,262],{},"Non (côté client)",[213,264,265],{},"Oui",[193,267,268,271,274,277],{},[213,269,270],{},"Intégration MQ native",[213,272,273],{},"Code custom nécessaire",[213,275,276],{},"Kafka Connect (config only)",[213,278,273],{},[193,280,281,284,286,288],{},[213,282,283],{},"Service managé AWS",[213,285,102],{},[213,287,136],{},[213,289,102],{},[19,291,292,293,296,297,299],{},"L'argument décisif n'était pas seulement la performance, mais ",[34,294,295],{},"la simplicité d'intégration",". Avec Kafka Connect et les connecteurs IBM Event Streams, nous pouvions adopter une approche ",[34,298,146],{}," : le Mainframe continue de déposer ses messages dans IBM MQ comme il l'a toujours fait, et le connecteur se charge du reste.",[23,301,303],{"id":302},"_3-la-solution-kafka-connect-comme-pont-bidirectionnel","3. La solution : Kafka Connect comme pont bidirectionnel",[84,305,307],{"id":306},"avant-après-vue-densemble","Avant \u002F après : vue d'ensemble",[19,309,310],{},[176,311],{"alt":312,"src":313},"Avant \u002F après : du batch de nuit (12 à 24 h de latence) au pipeline event-driven Mainframe → IBM MQ → Kafka Connect → Amazon MSK (quelques secondes).","\u002Fcontent-assets\u002F2026-05-04-mainframe-aws-reconcilier-deux-mondes-grace-a-levent-driven\u002Fassets\u002Fimg2.webp",[19,315,316],{},"Le contraste est radical : le batch de nuit, linéaire et bloquant, cède la place à un pipeline d'événements continu où chaque mouvement remonte en quelques secondes.",[19,318,319,320,322,323,326,327,332,333,44],{},"La solution retenue est d'utiliser ",[34,321,130],{}," pour faire le pont entre le monde IBM MQ (la messagerie native du Mainframe) et ",[91,324,136],{"href":134,"rel":325},[95]," (Managed Streaming pour ",[91,328,331],{"href":329,"rel":330},"https:\u002F\u002Fkafka.apache.org\u002F",[95],"Apache Kafka",") et ce pont fonctionne ",[34,334,335],{},"dans les deux sens",[84,337,339],{"id":338},"sens-mainframe-aws-source","Sens Mainframe → AWS (source)",[19,341,342],{},"Le Mainframe dépose un événement dans une file MQ. Le connecteur l'ingère et le transforme en topic Kafka.",[344,345,351],"pre",{"className":346,"code":347,"language":348,"meta":349,"style":350},"language-plain shiki shiki-themes github-dark-default","# CONFIGURATION 1 : Ingestion (MQ -> Kafka)\nconnector.class=com.ibm.eventstreams.connect.mqsource.MQSourceConnector\nmq.queue=MQ_KAFKA\ntopic=msk-serverless-tutorial\nmq.record.builder=com.ibm.eventstreams.connect.mqsource.builders.DefaultRecordBuilder\n","plain","text","",[352,353,354,362,368,374,380],"code",{"__ignoreMap":350},[355,356,359],"span",{"class":357,"line":358},"line",1,[355,360,361],{},"# CONFIGURATION 1 : Ingestion (MQ -> Kafka)\n",[355,363,365],{"class":357,"line":364},2,[355,366,367],{},"connector.class=com.ibm.eventstreams.connect.mqsource.MQSourceConnector\n",[355,369,371],{"class":357,"line":370},3,[355,372,373],{},"mq.queue=MQ_KAFKA\n",[355,375,377],{"class":357,"line":376},4,[355,378,379],{},"topic=msk-serverless-tutorial\n",[355,381,383],{"class":357,"line":382},5,[355,384,385],{},"mq.record.builder=com.ibm.eventstreams.connect.mqsource.builders.DefaultRecordBuilder\n",[84,387,389],{"id":388},"sens-aws-mainframe-sink","Sens AWS → Mainframe (sink)",[19,391,392],{},"Les applications modernes sur AWS peuvent aussi renvoyer de l'information (ex: validation d'opération) au Mainframe. Kafka Connect lit le topic et écrit dans la file MQ.",[344,394,396],{"className":346,"code":395,"language":348,"meta":349,"style":350},"# CONFIGURATION 2 : Restitution (Kafka -> MQ)\nconnector.class=com.ibm.eventstreams.connect.mqsink.MQSinkConnector\nmq.queue=KAFKA_MQ\ntopic=msk-serverless-tutorial\nmq.connection.mode=client\n",[352,397,398,403,408,413,417],{"__ignoreMap":350},[355,399,400],{"class":357,"line":358},[355,401,402],{},"# CONFIGURATION 2 : Restitution (Kafka -> MQ)\n",[355,404,405],{"class":357,"line":364},[355,406,407],{},"connector.class=com.ibm.eventstreams.connect.mqsink.MQSinkConnector\n",[355,409,410],{"class":357,"line":370},[355,411,412],{},"mq.queue=KAFKA_MQ\n",[355,414,415],{"class":357,"line":376},[355,416,379],{},[355,418,419],{"class":357,"line":382},[355,420,421],{},"mq.connection.mode=client\n",[19,423,424,425,428],{},"L'avantage de cette solution, c'est qu'il n'y a ",[34,426,427],{},"aucune ligne de code à écrire pour l'ingestion",". Tout se passe par configuration.",[84,430,432],{"id":431},"un-exemple-concret-le-flux-darbitrage","Un exemple concret : le flux d'arbitrage",[19,434,435],{},[176,436],{"alt":437,"src":438},"Flux d'arbitrage assurance-vie : événement Arbitrage publié dans le Hub, consommé en parallèle par l'application documentaire et le Mainframe ; retour Personne du Mainframe vers les applications aval.","\u002Fcontent-assets\u002F2026-05-04-mainframe-aws-reconcilier-deux-mondes-grace-a-levent-driven\u002Fassets\u002Fimg3.webp",[19,440,441],{},"Pour illustrer ce bidirectionnel, prenons notre cas d'arbitrage assurance-vie :",[443,444,445,453,456,459],"ul",{},[446,447,448,449,452],"li",{},"Le système de gestion des contrats détecte un échec d'intégration → il publie un ",[34,450,451],{},"événement \"Arbitrage\""," dans le Hub",[446,454,455],{},"Le pipeline (filtrage + contrôle qualité) valide l'événement et le route vers les topics de sortie",[446,457,458],{},"Deux consommateurs reçoivent l'événement en parallèle :",[446,460,461,462,465],{},"Kafka Connect (côté Source) reprend cet événement, le republie dans le Hub, qui le distribue aux ",[34,463,464],{},"applications aval"," (Référentiel Personne et apps consommatrices)",[19,467,468],{},"Un seul événement métier, deux consommateurs, un aller-retour complet entre les deux mondes.",[23,470,472],{"id":471},"_4-standards-et-interopérabilité","4. Standards et interopérabilité",[19,474,475,476,479],{},"Pour que ce pont fonctionne à l'échelle (des dizaines de flux, pas un seul POC), il faut ",[34,477,478],{},"standardiser le contrat d'interface"," entre producteurs et consommateurs.",[84,481,483],{"id":482},"cloudevents-un-format-universel","CloudEvents : un format universel",[19,485,486,487,494,495,500,501,504,505,508,509,512,513,516,517,520,521,524,525,528],{},"Nous avons adopté ",[91,488,491],{"href":489,"rel":490},"https:\u002F\u002Fcloudevents.io\u002F",[95],[34,492,493],{},"CloudEvents"," (",[91,496,499],{"href":497,"rel":498},"https:\u002F\u002Fgithub.com\u002Fcloudevents\u002Fspec",[95],"spécification CNCF",") comme format d'événement. Chaque message transitant par le hub porte des métadonnées standardisées : ",[352,502,503],{},"source",", ",[352,506,507],{},"type"," et ",[352,510,511],{},"id"," (identifiant unique) sont ",[34,514,515],{},"requis"," par la spec, tandis que ",[352,518,519],{},"time"," (timestamp) et ",[352,522,523],{},"dataschema"," sont recommandés. Cela garantit la ",[34,526,527],{},"traçabilité de bout en bout"," et l'interopérabilité, quel que soit le transport (HTTP, AMQP, Kafka).",[84,530,532],{"id":531},"asyncapi-documenter-larchitecture-événementielle","AsyncAPI : documenter l'architecture événementielle",[19,534,535,536,543,544,551,552,555],{},"Comme ",[91,537,540],{"href":538,"rel":539},"https:\u002F\u002Fwww.openapis.org\u002F",[95],[34,541,542],{},"OpenAPI"," documente les API REST, ",[91,545,548],{"href":546,"rel":547},"https:\u002F\u002Fwww.asyncapi.com\u002F",[95],[34,549,550],{},"AsyncAPI"," décrit nos canaux événementiels en YAML : quels événements, quels formats, quels serveurs, quels protocoles. Un ",[34,553,554],{},"SDK est généré"," à partir de ces spécifications et distribué aux équipes productrices et consommatrices, garantissant un contrat d'interface cohérent sans effort manuel.",[84,557,559],{"id":558},"deux-types-dévénements","Deux types d'événements",[19,561,562],{},"Nous avons distingué deux catégories fondamentales :",[443,564,565,571],{},[446,566,567,570],{},[34,568,569],{},"Événement Métier"," (notification) : \"un arbitrage a échoué\", il signale qu'un fait s'est produit, sans embarquer toutes les données.",[446,572,573,576],{},[34,574,575],{},"Événement Data"," (propagation d'état) : réplication complète d'un jeu de données depuis le système maître vers N systèmes esclaves.",[19,578,579],{},"Cette distinction évite de surcharger le bus avec des payloads inutiles tout en garantissant la fraîcheur des données là où c'est nécessaire.",[23,581,583],{"id":582},"_5-le-pipeline-de-traitement","5. Le pipeline de traitement",[19,585,586],{},[176,587],{"alt":588,"src":589},"Workflow d'un événement dans le hub : filtrage, contrôle qualité, distribution vers les consommateurs ; les événements en échec partent en Dead Letter Queue.","\u002Fcontent-assets\u002F2026-05-04-mainframe-aws-reconcilier-deux-mondes-grace-a-levent-driven\u002Fassets\u002Fimg4.webp",[19,591,592],{},"Les événements ne transitent pas \"bruts\" dans le hub. Un pipeline en trois étapes assure la qualité et l'aiguillage des données :",[443,594,595,606,612],{},[446,596,597,494,600,605],{},[34,598,599],{},"Filtrage",[91,601,604],{"href":602,"rel":603},"https:\u002F\u002Faws.amazon.com\u002Flambda\u002F",[95],"AWS Lambda",") : vérifie que l'événement est attendu, correspond à un schéma connu, et n'est pas un doublon technique.",[446,607,608,611],{},[34,609,610],{},"Contrôle Qualité"," (AWS Lambda) : valide le contenu métier, champs obligatoires, cohérence des données, conformité au schéma CloudEvents.",[446,613,614,617],{},[34,615,616],{},"Distribution"," : routing intelligent vers les topics de sortie par domaine, consommés par N applications.",[19,619,620,621,628],{},"Si un événement échoue à l'une des deux étapes de validation, il est redirigé vers une ",[91,622,625],{"href":623,"rel":624},"https:\u002F\u002Fdocs.aws.amazon.com\u002FAWSSimpleQueueService\u002Flatest\u002FSQSDeveloperGuide\u002Fsqs-dead-letter-queues.html",[95],[34,626,627],{},"Dead Letter Queue (DLQ)",". Rien n'est perdu : l'événement est conservé pour analyse et rejeu éventuel, mais il ne \"pollue\" pas les consommateurs en aval.",[23,630,632],{"id":631},"_6-sécurité-et-fiabilité-zero-message-loss","6. Sécurité et fiabilité : zero message loss",[19,634,635],{},"Dans la banque, perdre un message signifie potentiellement perdre de l'argent ou une instruction client. C'est inacceptable.",[19,637,638,639,44],{},"Kafka Connect offre ici une garantie technique majeure : le ",[91,640,643],{"href":641,"rel":642},"https:\u002F\u002Fkafka.apache.org\u002Fdocumentation\u002F#semantics",[95],[34,644,645],{},"\"at-least-once delivery\"",[19,647,648],{},"Comment cela fonctionne-t-il concrètement ?",[443,650,651,657,663],{},[446,652,653,656],{},[34,654,655],{},"Transactions et Offsets"," : Le connecteur ne valide la lecture (\"commit via offset\") qu'une fois le message bien arrivé à destination.",[446,658,659,662],{},[34,660,661],{},"Résilience Réseau"," : Si le lien entre AWS et le Mainframe coupe :",[446,664,665,668],{},[34,666,667],{},"Garantie de bout en bout"," : De la file MQ source jusqu'au topic Kafka répliqué sur 3 Availability Zones (AZ), la donnée est toujours persistée avant d'être acquittée.",[19,670,671],{},"Nous passons d'un couplage temporel fort (le batch de nuit) à un couplage lâche mais ultra-robuste.",[23,673,675],{"id":674},"_7-retours-dexpérience-difficultés-et-prérequis","7. Retours d'expérience : difficultés et prérequis",[19,677,678],{},"La mise en place de ce pont n'a pas été sans embûches. Voici les principaux enseignements.",[84,680,682],{"id":681},"intégration-réseau-et-infrastructure","Intégration réseau et infrastructure",[443,684,685,691,697,709],{},[446,686,687,690],{},[34,688,689],{},"Proxy d'entreprise"," : L'environnement AWS tourne derrière un proxy corporate. Chaque composant (EC2, connecteurs) doit être configuré avec les bonnes exclusions (métadonnées AWS, endpoints MSK). Un oubli = un connecteur muet sans message d'erreur explicite.",[446,692,693,696],{},[34,694,695],{},"Résolution DNS"," : Les endpoints MSK Serverless nécessitent parfois une résolution DNS manuelle (fichier hosts) dans les sous-réseaux privés, car les VPC endpoints ne sont pas toujours immédiatement résolus.",[446,698,699,702,703,708],{},[34,700,701],{},"Accès restreint"," : Pas de SSH en environnement de pré-production, tout passe par ",[91,704,707],{"href":705,"rel":706},"https:\u002F\u002Faws.amazon.com\u002Fsystems-manager\u002F",[95],"AWS SSM (Systems Manager)",". Le debug d'un connecteur Kafka en panne devient un exercice de patience.",[446,710,711,714,715,720,721,724,725,730],{},[34,712,713],{},"Port spécifique"," : ",[91,716,719],{"href":717,"rel":718},"https:\u002F\u002Faws.amazon.com\u002Fmsk\u002Ffeatures\u002Fmsk-serverless\u002F",[95],"MSK Serverless"," utilise le port ",[34,722,723],{},"9098"," pour l'",[91,726,729],{"href":727,"rel":728},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fmsk\u002Flatest\u002Fdeveloperguide\u002Fiam-access-control.html",[95],"authentification IAM"," (différent du 9094 TLS classique). Une source de confusion récurrente.",[84,732,734],{"id":733},"compatibilité-et-formats","Compatibilité et formats",[443,736,737,749],{},[446,738,739,742,743,748],{},[34,740,741],{},"EBCDIC et formats fixes"," : Les messages MQ du Mainframe sont souvent dans des formats historiques (COPYBOOK). Il faut prévoir une transformation (",[91,744,747],{"href":745,"rel":746},"https:\u002F\u002Fdocs.confluent.io\u002Fplatform\u002Fcurrent\u002Fconnect\u002Ftransforms\u002Foverview.html",[95],"Single Message Transform"," dans Kafka Connect) pour produire du JSON exploitable.",[446,750,751,754],{},[34,752,753],{},"Rétrocompatibilité applicative"," : Certaines applications consommatrices tournent sur des frameworks anciens. Les librairies IAM et CloudEvents n'étant pas disponibles sur toutes les versions, des compromis de version ont été nécessaires.",[84,756,758],{"id":757},"gestion-des-doublons","Gestion des doublons",[19,760,761,762,765],{},"Le \"at-least-once\" implique des doublons possibles. Chaque consommateur doit être ",[34,763,764],{},"idempotent",", typiquement via une clé de déduplication sur l'identifiant métier (numéro de contrat + identifiant d'opération).",[84,767,769],{"id":768},"gouvernance-et-observabilité","Gouvernance et observabilité",[443,771,772,778,790],{},[446,773,774,777],{},[34,775,776],{},"Dictionnaire d'événements"," : Sans catalogue formalisé des événements (qui produit quoi, quel schéma, quelle fréquence), le hub devient rapidement une boîte noire. Nous avons mis en place une gouvernance dédiée avec un RACI clair.",[446,779,780,783,784,789],{},[34,781,782],{},"Monitoring unifié"," : Le Mainframe et AWS ont des outils très différents. Les métriques JMX des connecteurs sont remontées dans ",[91,785,788],{"href":786,"rel":787},"https:\u002F\u002Faws.amazon.com\u002Fcloudwatch\u002F",[95],"CloudWatch"," pour unifier la supervision. Le hub doit pouvoir émettre à tout moment une synthèse d'activité (qui a publié, qui a consommé).",[446,791,792,795,796,798,799,801],{},[34,793,794],{},"FinOps"," : Le coût se joue à deux endroits. Côté AWS, ",[34,797,719],{}," (facturation à l'usage, pas de cluster à dimensionner en amont) limite l'investissement initial et s'adapte aux montées en charge réelles. Côté Mainframe, le licensing ",[34,800,167],{}," pèse lourd, mais Kafka Connect, qui consomme MQ de manière native, permet de le maintenir comme couche transitoire. Les équipes Mainframe planifient ainsi son décommissionnement à leur rythme, sans bloquer le déploiement du hub côté AWS.",[84,803,805],{"id":804},"conduite-du-changement","Conduite du changement",[19,807,808,809,812],{},"Les équipes Mainframe ne connaissent pas Kafka, et les équipes Cloud ne connaissent pas MQ. Un effort de ",[34,810,811],{},"montée en compétence croisée"," est indispensable, c'est peut-être le prérequis le plus sous-estimé.",[23,814,816],{"id":815},"_8-conclusion","8. Conclusion",[19,818,819],{},"Le résultat ? Le conseiller bancaire voit désormais les mouvements de son client quelques secondes après qu'ils aient eu lieu, et non le lendemain.",[19,821,822],{},"Nous avons \"réveillé le dinosaure\" sans le brusquer. Moderniser le Legacy ne signifie pas nécessairement tout réécrire (\"Big Bang\"). Parfois, il suffit de construire les bons ponts pour exposer la valeur existante aux nouveaux usages.",[19,824,825],{},"Les clés de cette réussite :",[443,827,828,834,840,846],{},[446,829,830,833],{},[34,831,832],{},"Configuration over Code"," : Kafka Connect évite de toucher au COBOL",[446,835,836,839],{},[34,837,838],{},"Standards ouverts"," : CloudEvents + AsyncAPI comme contrat d'interface universel",[446,841,842,845],{},[34,843,844],{},"Pipeline de qualité"," : Filtrage et validation avant distribution, avec DLQ pour le rejeu",[446,847,848,851],{},[34,849,850],{},"Gouvernance dès le jour 1"," : Dictionnaire d'événements, monitoring unifié, FinOps",[19,853,854],{},"Le Mainframe n'est pas mort. Il a juste besoin qu'on lui construise les bonnes passerelles.",[856,857,858],"style",{},"html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}",{"title":350,"searchDepth":364,"depth":364,"links":860},[861,862,867,873,878,879,880,887],{"id":25,"depth":364,"text":26},{"id":65,"depth":364,"text":66,"children":863},[864,865,866],{"id":86,"depth":370,"text":87},{"id":122,"depth":370,"text":123},{"id":150,"depth":370,"text":151},{"id":302,"depth":364,"text":303,"children":868},[869,870,871,872],{"id":306,"depth":370,"text":307},{"id":338,"depth":370,"text":339},{"id":388,"depth":370,"text":389},{"id":431,"depth":370,"text":432},{"id":471,"depth":364,"text":472,"children":874},[875,876,877],{"id":482,"depth":370,"text":483},{"id":531,"depth":370,"text":532},{"id":558,"depth":370,"text":559},{"id":582,"depth":364,"text":583},{"id":631,"depth":364,"text":632},{"id":674,"depth":364,"text":675,"children":881},[882,883,884,885,886],{"id":681,"depth":370,"text":682},{"id":733,"depth":370,"text":734},{"id":757,"depth":370,"text":758},{"id":768,"depth":370,"text":769},{"id":804,"depth":370,"text":805},{"id":815,"depth":364,"text":816},"2026-05-04T12:28:37.016Z","Comment réconcilier 80 à 90 % des données métier coincées dans un Mainframe IBM avec des applications cloud-native qui exigent l'instantané ? Retour d'expérience sur la construction d'un pont event-dr","md",".\u002Fassets\u002Fcover-image.webp",{},true,"\u002Fblogs\u002F2026-05-04-mainframe-aws-reconcilier-deux-mondes-grace-a-levent-driven",[896],{"id":897,"name":898,"image":899,"linkedin":900,"x":901},"e8163b24-7e01-41c5-adbf-0dc655f929d0","Nicolas Zago",".\u002Fassets\u002Freviewer-nicolas-zago.webp","https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fnicolaszago\u002F",null,{"title":6,"description":889},"blogs\u002F2026-05-04-mainframe-aws-reconcilier-deux-mondes-grace-a-levent-driven\u002Findex",[905,906,907,908,909],"architecture","cloud-platform","cloud","kafka","event driven architecture","33nLawacWxzcOggJs-mxD-uYhrQLmljKKAj6WV-dk5Q",1777898852956]